Should we instead make deniedTypes a var and just set it to an empty array?

will that be backward compatible change

also the events might be nice to have?

we can probably have an event that says types cleared to make it more efficient. and lemme check if it's a backward compatible change, my gut says no

will that be backward compatible change

I believe changing let to var is an an upgradable change yes

also the events might be nice to have?

👍 Sure, totally fine to add events. That might require some discussion so if you need some way to remove types right now for testing purposes, I'd split them up.

is it worth it to do the let/var change if we want to iterate through every key to emit each event?

Will it be helpful for each removed type to be included in its own event or could we emit an array of removed types? If the latter, I think we could use the same event for both removal operations and just emit the dict keys

Emitting an array is what I was thinking, yeah. It depends on what kinds of events you're thinking about @rrrkren. Is there any high-level thought on that yet that we can use to think through this?

this is what we are doing right now to reset filters:

        let filterDetails = filter.getDetails() as! {String:AnyStruct}
        for allowedType in filterDetails["allowedTypes"]! as! [Type]{
            filter.removeType(allowedType)
        }

I'd prefer to keep this PR as is if possible since it's just a sugared iterate remove all and doesn't require downstream event aggregations to change. Happy to discuss further on the single filter reset event as a follow up.

Looks like the file needs to be renamed - remoe_all_types.cdc -> remove_all_types.cdc. Small typo is causing this test case to fail